Software Metrics for Package Remodularisation

There is a plethora of software metrics [LK94, FP96, HS96a, HK00, LM06] and a large amount of research articles. Still there is a lack for a serious and practically-oriented evaluation of metrics. Often metrics lack the property that the software reengineer or quality expert can easily understand the situation summarized by the metrics. In particular, since the exact notion of coupling and cohesion is complex, a particular focus on such point is important. In the first chapter of the present document, we present a list of software metrics, that are commonly used to measure object-oriented programs. In the second chapter we present our proposition for package metrics that capture package aspects such as information hiding and change impact limits. ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 Cutter ANR 2010 BLAN 0219 02 INRIA LNE-LIRMM Chapter1. State of the Art on Software Metrics In this chapter we present some of the software metrics that are the foundation of most software quality models. We sort them in the following groups: Primitive metrics and Design metrics. Design metrics deal with design principles. They quantify over source code entities to assess whether a source code entity is following a design principle. In particular, such metrics can be used to track down bad design, and correcting these could lead to an overall improvement. • Primitive metrics: simple metrics capturing some structural aspects. • Design Metrics: Class cohesion metrics are in particular relevant for remodularisation. • Design Metrics: Class coupling metrics are in particular relevant for remodularisation. • Design Metrics: Package architecture. They are the first metrics taking into account the fact that a package is not just a class at another level of granularity. 1.1 Primitive Metrics Primitive metrics target some basic aspects of source code entities (DIT, NOM), or a simple combination of other primitives (WMC, SIX) to give an abstract, comparable view of such entities. While simple to understand, their interpretation depends highly on the context, including the program, its history, the programming language used, or the development process followed by the team. The following metrics are known as the CK metrics because Chidamber and Kemerer grouped them to define a commonly used metric suite [CK94b]: • WMC • DIT • NOC • RFC Some other primitive metrics have been defined by Lorenz and Kidd [LK94] : • NOM • NIM • NRM • SIX Note that we do not list LCOM here since it was heavily criticized and revised. We discuss it in the cohesion part below. In addition it should be noted that many metrics and thresholds as defined by Lorentz are unclear or do not make real sense. 2 ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 INRIA LNELIRMM Cutter ANR 2010 BLAN 0219 02 Names Depth of Inheritance Tree, Hierarchy Nesting Level Acronyms DIT, HNL References [LK94, CK94b, BMB96, GFS05, LH93a, HM95, TNM08] Definition The depth of a class within the inheritance hierarchy is the maximum length from the class node to the root of the tree, measured by the number of ancestor classes. The deeper a class within the hierarchy, the greater the number of methods it is likely to inherit, making it more complex to predict its behavior. Deeper trees constitute greater design complexity, since more methods and classes are involved, but enhance the potential reuse of inherited methods. Scope Class Analysis There is a clear lack of context definition. DIT does not take into account the fact that the class can be a subclass in a framework, hence has a large DIT but in the context of the application a small DIT value. Therefore its interpretation may be misleading. Since the main problem with DIT is that there is no distinction between the different kinds of inheritance, Tempero et al. [TNM08] have proposed an alternative for Java. They distinguish two kinds of inheritance in Java: extend and implement. They distinguish three domains: user-defined classes, standard library and third-party. They have introduced new metrics to provide on how much inheritance occurs in an application. Unfortunately, they do not propose metrics for indicator of "good-design" or fault predictor. DIT measures the number of ancestor classes that affect the measured class. In case of multiple inheritance the definition of this metric is given as the longest path from class to the root class, this does not indicate the number of classes involved. Since excessive use of multiple inheritance is generally discouraged, the DIT does not measure this. Briand et al. [BMB96] have made an empirical validation of DIT, concluding that the larger the DIT value, the greater the probability of fault detection. Gyimothy et al. [GFS05] conclude that DIT is not as good predictor of fault than the other set of CKmetrics and they say that this metric needs more investigation to confirm their hypothesis : "A class located lower in a class inheritance lattice than its peers is more fault-prone than they are". Moreover, DIT was really often studied but in most cases this was made with programs with few inheritance, and therefore this metric needs more empirical validation for programs with more inheritance. Li and Henry [LH93a] used the DIT metric as a measure of complexity, where the deeper the inheritance, the more complex the system is supposed to be. But as Hitz and Montazeri [HM95] notice, this means that inheritance increases the complexity of a system while it is considered a major advantage of the object-oriented paradigm. 3 ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 Cutter ANR 2010 BLAN 0219 02 INRIA LNE-LIRMM This metric as well as other CKmetrics should be put in perspective: one measure is not really significant but the change of values between two measures should bring more information. Also, this metric should be applied at different scope because of its different interpretation depending on the context: counting only the user-defined classes or the standard library too. Names Number of Children Acronyms NOC References [CK94b, GFS05] Definition Number of children counts the immediate subclasses subordinated to a class in the class hierarchy Scope Class Analysis This metric shows the impact and code reuse in terms of subclasses. Because of change may impact all children, the more children have a class, the more changes require testing. Therefore NOC is a good indicator to evaluate testability but also impact of a class in its hierarchy. Because of counting only immediate subclass, this metric is not sufficient to assess the quality of a hierarchy. Gyimothy et al. studied this metric and didn’t state that it is a good fault detection predictor. Briand et al. [BMB96] found NOC to be significant and they observed that the larger the NOC, the lower the probability of fault detection, which seems at first contradictory. Marinescu and Ratiu [MR04] characterize the inheritance with this 2 metrics : the Average Number of Derived Classes the average of direct subclasses for all the classes defined in the measured system (NOC) and the Average Hierarchy Height the average of the Height of Inheritance tree (DIT). These 2 metrics indicate not only if the inheritance is used by the system but also if there are classes which use inheritance. Names Number of Methods Acronyms NOM References [LK94] Definition NOM represents the number of methods defined locally in a class, counting public as well as private methods. Overridden methods are taken account too. Scope Class 4 ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 INRIA LNELIRMM Cutter ANR 2010 BLAN 0219 02 Analysis NOM is a simple metric showing the complexity of a class in terms of responsibilities. However, it does not make the difference between simple and complex methods. WMC is better suited for that. NOM can be used to build ratio based on methods. Names Weighted Methods Per Class Acronyms WMC References [CK94b] Definition WMC is the sum of complexity of the methods which are defined in the class. The complexity was originally the cyclomatic complexity. Scope Class Analysis This metric is often limited when people uses as weighted function the function fct = 1. In such a case it corresponds to NOM. This metric is interesting because it gives an overall point of view of the class complexity. Names Cyclomatic Complexity Metric Acronyms V(G) References [McC76] Definition Cyclomatic complexity is the maximum number of linearly independent paths in a method. A path is linear if there is no branch in the execution flow of the corresponding code. This metric could be also called "Conditional Complexity", as it is easier to count conditions to calculate V(G) which most tools actually do. V (G) = e− n+ p where n is number of vertices, e the number of edges and p the number of connected components. Scope Method, Class Analysis This metric is an indicator of the psychological complexity of the code: the higher the V(G), the more difficult for a developer to understand the different pathways and the result of these pathways which can lead to higher risk of introducing bugs. Therefore, one should pay attention to high V(G) methods. Cyclomatic complexity is also directly linked to testing efforts: as V(G) increases, more tests need to be done to increase test coverage and then lower regression risks. Actually, V(G) can be linked to test coverage metrics: 5 ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 Cutter ANR 2010 BLAN 0219 02 INRIA LNE-LIRMM – V(G) is the maximum amount of test cases needed to achieve a complete branch coverage – V(G) is the minimum amount of test cases needed to achieve a complete path coverage At class level, cyclomatic complexity is the sum of the cyclomatic complexity of every method defined in the class. Names Essential Cyclomatic Complexity Metric Acronyms eV(G) References [McC76] Definition Essential cyclomatic complexity is the cyclomatic complexity of the simplified graph i.e. the graph where every well structured control structure has been replaced by a single statement. For instance, a simple "if-then-else" is well structured because it has the same entry and the same exit: it can be simplified into one statement. On the other hand, a "break" clause in a loop creates a new exit in the execution flow: the graph can not be simplified into a single statement in that case. ev(G) = v(G)−m where m is the number of subgraphs with a unique entry and a unique exit. Scope Method, Class Analysis This metric is an indicator of the degree of structuration of the code, which has effects on maintenance and modularization efforts. Code with lots of "break", "continue", "goto" or "return" clauses is more complex to understand and more difficult to simplify and divide into simpler routines. As for V(G), one should pay attention to methods with high essential cyclomatic complexity. Names Number of Inherited Methods Acronyms NIM References [LK94, BDPW98] Definition NIM is a simple measure showing the amount of behavior that a given class can reuse. It counts the number of methods which a class can access in its superclasses. Scope Class 6 ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 INRIA LNELIRMM Cutter ANR 2010 BLAN 0219 02 Analysis The larger the number of inherited methods is, the larger class reuse happens through subclassing. It can be interesting to put this metric in perspective with the number of super sends and self send to methods not defined in the class, since it shows how much internal reuse happens between a class and its superclasses based on invocation (the same can be done for incoming calls to methods inherited, although this is harder to assess statically). Also, inheriting from large superclasses can be a problem since maybe only a part of the behavior is used/needed in the subclass. This is a limit of single inheritance based objectoriented programming languages. Names Number of overRiden Methods Acronyms NRM References [LK94] Definition NRM represents the number of methods that have been overridden i.e., defined in the superclass and redefined in the class. This metric includes methods doing super invocation to their parent method. Scope Class Analysis This metrics shows the customization made in a subclass over the behavior inherited. When the overridden methods are invoked by inherited methods, they represent often important hook methods. A large number of overridden methods indicates that the subclass really specializes its superclass behavior. However, classes with a lot of super invocation are quite rare (For the namespace VisualWorks.Core there are 1937 overridden methods for 229 classes: an average equals to 8.4 overridden methods per class) When compared with the number of added methods, this comparison offers a way to qualify the inheritance relationship: it can either be an inheritance relationship which mainly customizes its parent behavior or it adds behavior to its parent one. However, Briand et al. [BDPW98] conclude that the more overriding methods used, the more faultprone software system becomes. Names Specialization IndeX Acronyms SIX References [LK94, May99] Definition SIX = NRM ×DIT NOM +NIM 7 ha l-0 06 46 87 8, v er si on 1 1 D ec 2 01 1 Cutter ANR 2010 BLAN 0219 02 INRIA LNE-LIRMM The Specialization Index metric measures the extent to which subclasses override their ancestors classes. This index is the ratio between the number of overridden methods and total number of methods in a Class, weighted by the depth of inheritance for this class. Lorenz and Kidd precise : "Methods that invoke the superclass’ method or override template are not included".